The creation of software applications requires a high degree of programming knowledge and experience on the part of the developer during the design of the software architecture. An application is usually created almost exclusively monolithically and hence as an application block, which must always be changed as a whole when changes are required, e.g. in the context of software updates. This entails a significant cost when the application is created and when it is maintained. Furthermore, these monolithic systems are relatively susceptible to error.
In addition to applications for desktop use, in which the application layers can be executed exclusively on a shared computer, web applications also exist in which the application layers are designed for running on a client-server structure, i.e. on a plurality of computers. Web applications then require the client-server structure, however, and cannot therefore be used without a server.
In conventional application systems, provision is made for an application to access individual libraries in the form of a dynamic or static link, and to be executed within an execution file in the form of an executable. Within this concept, the applications rely on a multiplicity of different services, components and data which are made available to the relevant calling application in different hierarchical layer levels of the underlying software architecture. These services are usually implemented directly in the source code of an application, wherein the services and components sometimes run on different platforms, such as e.g. Windows-based or Linux-based operating systems, and on different runtime locations within a computer network, such as e.g. desktop computers or web-based server-client configurations. Subsequent adaptation or modification of the application to suit changed platform environments and/or other runtime locations, also known collectively as deployment, is not possible due to the respectively different software architecture for the various deployments.
When creating a software architecture for an application, it is therefore problematic that in the event of a change or adaptation to other working environments or to other deployments, it has been necessary until now to adapt the underlying software architecture, which usually requires extensive changes. As part of this, the developer must above all specify the arrangement of the architecture layers of the application on the relevant computer structure of the different deployments anew in each case. In particular, a new software architecture for the application must be defined, and a new source code must be created and complied in an execution file in the form of an executable. These measures entail a significant cost in terms of time and resources for the creation of the respective applications, and currently require the parallel development of different applications having varying computer application software architectures for different deployments.
For this reason, so-called frameworks are provided as support environments for developers, the frameworks frequently encapsulating the individual layers of a software application within a generic runtime environment. An application layer which—embedded in a generic runtime environment—can be run individually and independently of platform and/or runtime location is designated as encapsulated.
The .NET framework of the Microsoft Corporation is an important framework. This framework offers the possibility of utilizing all variety of programming languages such as C#, Visual Basic.NET, C++/CLI or JScript.NET as a basis for programming an n-layered application. Irrespective of the type of programming language that is utilized, the application and/or relevant architecture layer of the application is converted into an “intermediate language” (Microsoft Intermediate Language: MSIL). The application which is thus programmed in the intermediate language is then compiled and converted into an execution file.
The application programming interfaces (API) which are required between the individual layers of the application are very important in this case. A distinction is made between function-oriented, interface-oriented and protocol-oriented application programming interfaces. Unlike function-oriented and interface-oriented application programming interfaces, protocol-oriented application programming interfaces are independent of the operating system of the platform and independent of the type of application layers which must be connected. An application programming interface which has been defined once between two encapsulated layers cannot currently be changed, however, and therefore a separate quasi-monolithic software application is required in each case with reference to the respective deployments.
DE 698 19 188 T2 therefore describes a program interface converter for computers using a plurality of environments. According to the invention claimed therein, a utility program automatically produces and updates code modules for translating application programming interfaces which have been written for one platform, in order that they can be executed correctly on another platform. The utility program, which is executed for each new development step of an operating system or other software environment, works with a range of templates for producing the source code for the translation modules on the basis of the functions which are executed by the application programming interfaces.
DE 699 08 121 T2 likewise describes an application programming interface in an operating system. The invention therein specifies a system containing a set of application programming interfaces for a number of software modules and software components for environments having limited resources. An example of an environment having limited resources is an integral system comprising a multiplicity of consumer devices and specialized industrial controllers including hand-held or palm-size PCs.
All of the methods disclosed in the prior art for producing an n-layered application by way of a framework have the disadvantage that, although the application programming interfaces can be converted with reference to the required platforms and runtime locations, it has not been possible until now to utilize the interaction of the layers via the respective intermediate application programming interfaces, the interaction having been determined for one deployment, for another deployment. Consequently, parallel developments of source code masters are required for the different deployments.